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Introduction 


Mobile developers are faced with a variety of 
different platforms, operating systems, 
languages and technical specifications when 
creating games 


Being able to deliver and adapt applications 
guickly to all existing platforms is vital 
this market 


Portable code is the key to fast and problem- 
free application turn-around 


in 
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What is portable 

code? 

• Portable code is "good code" - 
well designed, well structured, 
well documented and well 
implemented 

• Portable code makes it easy and 
quick to understand its 
functionality 

• Portable code can easily be 
adapted to other environments 
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Portable code does not necessarily 
eradicate the need for code 
changes . Its purpose is to 
minimize them! 
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Think ahead 


• No mobile game exists in a 
vacuum and by nature has to 
serve a large number of 
environments 

• Do not limit your thinking to 
your platform of choice 

• Keep all potential environments 
in mind 

• Keep all potential requirements 
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Think ahead 


• Chances are, your code is not 
for your eyes only 

• Comment your code to make future 
changes and ports easy and pain- 
free 

• Comment your code, because it's 
good practice! 
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Take pride in your 

code 

Unlike graphic artists and musicians, programmers often 
do not take pride in their actual code. The result are 
shoddy implementations, dirty tricks, illegible code, 
unintelligible implementations that hide bugs, and 
code that is simply not up to snuff. 

It is part of the reason why there are so many buggy 
games on store shelves! 

The quality of your source code is 
just as important as your 
executable code! 
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The kinds of 
portability 

• Across platforms (Brew, Symbian, Windows CE) 

- Needs to abstract platform dependencies, 
such as File 10, User Interface, Bootstrap, 
etc . 

• Across languages (c, C++, j 2 me) 

- Needs to assimilate language features 

• Across handsets (t720, vx6000,...) 

- Needs to abstract hardware differences, 
such as display resolutions, audio 
capabilities, firmware bugs, etc. 
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Project organisation 


Directory structure 

^ Group directory 

^ Platform/language 
directory 

> Handset-specific 
directory 


The deeper the directory structure 
goes, the more specialized the 
items within get 


□ Fliplt 
B CJ asset files 
B Q Brew 

Q ColoM28x128 
Q CoIol240x292 
CD Color_9Gx54 
CJ Colof_96x65 
B C] assets 

Q ColorJ28x128 
Q Color_240x292 
Q Color_9Gx54 
. O Colof_9GxG5 
Q SaveData 
CD documentation 
S CD projects 
B CD Brew 
B CD AppLoad 
^ B CD colotJ28x128 
Q ARM 
Q DOC 
Q WIN 

B C] colot_240x292 
: B Q colot_9Bx54 
B CD color_9BxG5 
B CD Release Versions 
Q V100c128en 
QV110c128en 
B CD ArmRel 
i Q ColoM28x128 
Q Color_240x292 
Q Color_9Bx54 
CD Color_9Bx5G 
CD Debug 
CD VTune 
B CD source 
B CD bak 

(C] Brew 
Q DeviceData 
Q J2ME 
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Directory structure 


The "Asset Files" directory 
contains the discrete asset 
data, such as maps, images, 
audio files, data files, 
scripts, etc. 

Data become more specialized the 
deeper we get in the hierarchy 

asset f iles/brew/color_128xl28 
contains data only relevant to 
that particular environment 

asset files/brew contains data for 
all Brew handsets 

asset files contains data that are 
relevant to all environments 
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□ Flipit 
B-Q asset files 
B ■Tp Brew 

I i •C] CoIol128h128 

I I ■C] Color_240K282 

I -C] CoIol9Gk54 
I Color_86x65 



Directory 


The "Assets" directory 
contains the prepared 
asset data, such as 
maps, images, audio 
files, data files, 
scripts, etc. in the 
form of BAR files, data 
library files, or any 
format of choice 

Data in these directories 
are typically tool- 
generated and represent 
the data in the form 
the application can use 

It also contains the 
untouched, original 
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structure 


hi ■Th assets 1 

l-Q 

Color_128Kl28 

i-Q 

Color_240K282 

i-Q 

Color_8GK54 

l-Q 

Color_8GKG5 

i...Q 

SaveData 
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Directory structure 


The "Projects" directory 
contains Visual Studio 
solution files^ EVC 
projects, make-files, as 
well as all compiled 
program code, complete 
builds and archived 
versions of previous 
production builds 

"AppLoad" and "ArmRel" are 
used to separate 
intermediate builds from 
final builds 

.../brew/ appload/ color_128xl28 
contains the complete 
submission/release package 

Game 


S 'Cll projects 
S'Cll Brew 

B -Q] AppLoad 

I i a-Q color_128Kl28 

i -C] arm 
I i-'Cl DOC 

I l-Cl WIN 

[f-Q] color_240K282 
B-Q] coIoi_86x54 
B-Q color_8Gx65 
S-Q] Release Versions 
i -Cl V100c128en 
bQvi10c128en 
aTt ArmRel 

I i •C] Color_1 28x1 28 

I i-C] Color_240x282 

I i -C] Color_88x54 

i -C] Color_8Gx58 

i-Cl Debug 
I bQ VTune 
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Directory structure 


The "Source" directory 
contains all the source 
code for the application 

source/brew contains all the 
platform dependent code 
parts for the Brew builds 

source/ppc contains the 

platform dependent code for 
the Pocket PC version, and 
so forth... 

source/devicedata contains 
the necessary device- 
specific source code for 
particular environments 


□ C] Fliplt 
□■■Q source 
i-Tt Brew 
i '-Q] DeviceData 
DirectX 
i •C] PPC 
h-Q] Smartphone 
'■ ■CH SiJmbian 
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Directory structure 


The key to a good project 
directory structure 

• Keep it extensible 

• Keep it clear 

• Keep it structured 

• Keep out the clutter 
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with this sort of directory 
structure we have 
created an easy way to 
physically separate 
device-dependent code 
from general game code 

In the project we now 

simply create wrappers 
to load the platform 
specific implementations 
during compile time 

Create wrappers for both 
header and source code 
files 

Examples for typical 
platform dependent 
implementations are 
application startup, 
memory manager, display 
handling, input 
handling, file 10, and 
various utility 

Gam^ 2004 
sprite blitting, debug 


// 

// UTILITY. CPP 
// 

// Author: Henkel 
// Date: 04/17/03 

// 

// This file contains uarious wrappers and 
// utility functions for the uarious platforms 
If 

ttifdef BREW_UERSI0N 

ttinclude "BREW/Utility .cpp" 
ttelif PPC_UERSI0N 

ttinclude “PPC/Utility .cpp" 
ttelif SVMBIftN_UERSION 

ttinclude "Synbian/Utility .cpp" 
ttelif SMflRTPH0NE_UERSI0N 

ttinclude "Snartphone/Utility .cpp" 
ttendif 
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Designing the 
framework 

To make all this work together 
effortlessly we need to create a 
framework that accommodates this data 
design in a way that is transparent 
and unobtrusive 

The way to do this is by using ^^hooks" 

Create an event driven application 
design using a finite state machine 
and use these hooks to drive the core 
of the application 
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static boolean 

EventHandler ( . . . Parameters . . . ) 

{ 

switch ( eventCode ) 

{ 

case E VT_AP P_S TART : 

ClearScreen ( curApp ) 

Memlnit ( curApp ) ; // Initialize memory manager 

GameStart ( curApp ) ; 

GamePostfix( curApp ) ; 
break; 

case EVT_APP_STOP : 

GameEnd ( curApp ) ; 

MemExit ( curApp ) ; // Exit the memory manager 

break; 

case EVT_APP_EVENT : // Special treatment may be 

GameEvent ( curApp ) ; // required here depending on 

break; // the actual platform 

case EVT_APP_SUSPEND: 

SuspendGame ( curApp ) ; 
break; 

case EVT_APP_RESUME ; 

ResumeGame ( curApp ) ; 
break; 

case EVT_KEY_PRESS: 

keyPressed( curApp, parameter ); 
break; 

case EVT_KEY_RELEASE : 

keyReleased( curApp, parameter ); 
break; 

} 

} 
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These are the hooks 
to platform 
independent code 
that drive the game 
engine 
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static boolean 

EventHandler ( . . . Parameters . . . ) 

{ 

switch ( eventCode ) 

{ 

case E VT_AP P_S TART : 

ClearScreen ( curApp ) 

Memlnit ( curApp ) ; // Initialize memory manager 

GameStart ( curApp ) ; 

GamePostfix ( curApp ) ; 

break; 

case EVT_APP_STOP : 

GameEnd ( curApp ) ; 

MemExit ( curApp ) ; // Exit the memory manager 

break; 

case EVT_APP_EVENT : // Special treatment may be 

GameEvent ( curApp ) ; // required here depending on 

break; ■'/ the actual platform 

case EVT_APP_SUSPEND: 

SuspendGame ( curApp ) ; 

break; 

case EVT_APP_RESUME : 

ResumeGame ( curApp ) ; 

break; 

case EVT_KEY_PRESS: 

keyPressed( curApp, parameter ) ; 

break; 

case EVT_KEY_RELEASE : 

keyReleased( curApp, parameter ) ; 

break; 
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These are the hooks 
to platform 
independent code 
that drive the 
game engine 

With this interface 
we abstract the 
core platform 
dependencies 

This core can be 
created for 
virtually every 
environment today 

And it can easily 
be extended to 
add 

functionality, 
such as stylus 
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static boolean 

EventHandler ( . . . Parameters . . . ) 

{ 

switch ( eventCode ) 

{ 

case E VT_AP P_S TART : 

ClearScreen ( curApp ) 

Memlnit ( curApp ) ; // Initialize memory manager 

GameStart ( curApp ) ; 

GamePostfix ( curApp ) ; 

break; 

case EVT_APP_STOP : 

GameEnd ( curApp ) ; 

MemExit ( curApp ) ; // Exit the memory manager 

break; 

case EVT_APP_EVENT : // Special treatment may be 

GameEvent ( curApp ) ; // required here depending on 

break; ■'/ the actual platform 

case EVT_APP_SUSPEND: 

SuspendGame ( curApp ) ; 

break; 

case EVT_APP_RESUME : 

ResumeGame ( curApp ) ; 

break; 

case EVT_KEY_PRESS: 

keyPressed( curApp, parameter ) ; 

break; 

case EVT_KEY_RELEASE : 

keyReleased( curApp, parameter ) ; 

break; 

} 

} 
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Think about it 


The key to successfully creating 
portable code is to look for and 
find a common denominator 

This applies to both, platforms 
and operating systems, as well 
as language features 

The more you know about your 
targets, the easier you will 
find it to set up these common 
denominators 
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Creating a common 

base 


J2ME doesn't have a pre-processor, 
so it is advisable to use C/C++ 
greater flexibility to 
assimilate J2ME behavior 


Since Brew doesn't have a global variable 
name space we can create a macro to 
"simulate" this name space if we have to. 
Use this feature judiciously^ however! 

fdefine ScreenWidth (Applet->ScreenWidth) 
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Creating a common 

base 


J2ME has hard-wired keyPressed ( ) , 
keyReleased ( ) , and paint () 
interfaces for certain objects 


You will make your life much easier 
if you stick to that naming 
convention in C/C++ as well^ even 
if it breaks with your own naming 
convention 
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Creating a common 

base 


J2ME does not support operator 
overloading or templates 


While these are powerful and tempting 
features for every C++ programmer 
to use^ you may want to stay away 
from them in preference of higher 
portability 
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Creating a common 

base 

J2ME does not have pointers^ only 
arrays 

Given today's CPU architecture^ 
pointers are also no longer 
necessarily faster - especially on ARM 
processors in Thumb mode 

for (i=0; i<100; i++) 

{ 

*dest++ = *src++; 

} 


The problem with this loop is that it will have to be re- 
written for the J2ME version and in terms of 

^g^nqehgO^ocessor has to increment the 



Creating a common 

base 

for (i=0; i<100; i++) 

{ 

dost [ i ] = src [ i ] ; 

} 

This version is portable AND more 

powerful on today' s CPU' s because only 
the iterator needs to be incremented^ 
and because existing opcodes allow to 
pre-multiply the index as an 
addressing mode^ making array access 
in a single instruction possible even 
Gamew^ilebpevar^i^blae 2@prray element sizes. 
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Creating a common 

base 


Brew does not support exception 
handling 


Make sure you use it judiciously in 
your other versions and try to 
instead rely on other means of 
error detection 


Game Developers Conference 2004 


26 



Creating a common 

base 


Brew does not support static class 
variables or global-scope variables 

If you have to create persistent class 

variables, place them in the global applet 
structure, and maybe use a special naming 
convention to indicate their class- 
ownership 

Alternatively, create a "friend" super-class 
that holds only those elements that need 
to remain static. Keep in mind however 
that in Java, each class has a memory 
overhead that can be severe in tiqht 
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Creating a common 

base 


stay away from dirty programming 
tricks ! 


Using J2ME's out-of-bounds exception 
handling to detect array sizes is 
very bad practice and barely 
portable 
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General tips 

and 

good habits 
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Good habits 


Many programmers seem reluctant to make 
full use of the tools that modern 
compilers put at their fingertips. 
There are a few things that 
intrinsically make your life as a 
programmer easier^ and help making 
your code more stable and safer 

One should think that applying some of 
these methods is common sense^ but 
still they are applied far too 
infrequently in my experience. Here 

Ga.eTOlo?e9I^?on^erW=g^?odonS... 
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Good habits 


Source code is cheap, so use it! 

Good programming style occasionally 
requires you to write more source 
code than otherwise^ but the payoff 
is usually enormous 

There is no room for laziness in 
programming ! 
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Good habits 


• Only one command per line 

• Properly indent and bracket your code 

• Work with a sensible style guide and 
stick to it 

• Apply some common sense and don't try 
to be a ^'cool" coder. Ultimately 
you're making your own life 
unnecessarily harder 

• Never add a call to a particular OS- 
specific function to your game engine 
code - write a custom version instead^ 

Gamet^kabp^sirnpflyncf ooowards the call to the 32 


Lose the #define 

macros 

The single-most abused feature of C and 
C++ is the #define pre-processor 

command 

Use const to create constant values 

^ const has scope and a name space. It is 
type-safe and allows the compiler to 
optimize your code much better 

^ const can quickly be turned into a 

variable without much code change. Great 
for experimentation before locking down 
final values 

^ Despite Brew' s inability to create global 
variables, const can be used to create 

Game using the Syntax 
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Lose the #define 

macros 

There are valid uses for #define. 
Make sure you use it only in 
such cases, and keep in mind 
that even simple macros like the 
one below can turn into deadly 
traps 


#define max ( a, b ) ((a) > (b) ? (a) : (b) ) 
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Lose the #define 

macros 

#define max ( a, b ) ((a) > (b) ? (a) : (b) ) 

Now, imagine this... 

int a = 5, b = 0; 

max ( ++a, b ) ; 
max ( ++a, b+10 ) ; 

The results of this little exercise are fatal 
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Lose the #define 

macros 

A much better way to solve this 
problem is to use an inline 
function, such as this 


inline int max ( int a, int b) { return a > b ? a : b; } 


This may not be perfect, but since we can't use 
templates, it's certainly the next best thing 
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Say ''No" to Hungarian 

Notation 


• It is unwieldy and error-prone 

• It is counterproductive and hard 
to maintain 

• It reveals implementation 
specifics as part of a class 
interface 
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Finite State Machines 


• Use of Finite State Machines 
greatly increase the portabi 
of a code base 

- Inherently iterative 

- Easy to understand and extend 

- Non-blocking 


can 

lity 
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Heed your compiler 

warnings 

Always set your compiler to highest warning levels - 
Level 4 in Visual Studio 

Make sure your project compiles with 0 warnings 

Do not use #pragma to turn off warnings as it is 

compiler-specific and may silently turn off vital 
warnings in another environment 

if a warning is unavoidable, comment the line of code 
in question, explaining why the warning cannot be 
circumvented 

Warnings are usually a sign of sloppy laziness, which 
has no place in professional game development 

Warnings often reveal actual bugs that are discovered 
as you inspect your code for the cause of the 


warning 
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Putting together a 

game 
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The framework 


• Write an application framework 
that is reusable, portable and 
extensible 

• Include implementations for 
application startup, memory 
manager, display handling, input 
handling, file 10, and various 
utility functions, such as 
sprite blitting, debug logging, 
handset detection, etc. 
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The framework 


• Memory manager 

- Make sure to overload new and delete as 
well as new [ ] and delete [] 

void *operator new ( size_t size ) ; 
void operator delete ( void *ptr ) ; 
void ^operator new [ ] ( size_t size ); 
void operator delete [] ( void *ptr ) ; 


- Add debugging tools if you wish, such as 
bounds-checking, leak detection, and other 
statistics 

- Having good new and delete implementations 
1 found that mallocO became virtually 
redundant 
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The framework 


• Display handling 

- Create an abstract interface - I am 
typically using a GAPI-style interface 
because it is small and very tight, 
providing only the essentials 

- If you work with direct framebuffer access, 
be prepared to write your routines for 
RGB444, RGB555 and RGB565 color triplets in 
16-bit modes. You may not have to implement 
them immediately - just keep in mind that 
there are devices with these configurations 
that you may run into some time down the 
line 
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The framework 


• File 10 

- Despite providing basic file 10 such as 
openO, close 0, read() and write () I found 
it much more useful in mobile applications 
to provide specific loading routines 

• LoadImageO 

• LoadData ( ) 

• ReadFileO, WriteFileO 

- This usually removes repetitive coding and 
error-checking^ and provides you with 
tighter calls in your game engine that are 
plat form- independent 
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The framework 


• File 10 

- Never access files directly by name. Use a constant 
instead. That way you keep it portable between 
platforms where files are loaded by name and those 
where they are loaded by ID from a resource file 

• J2ME 

static final char FileName[] = "datafile.dat"; 

• Brew 

const int FileName = DAT_DATAFILE; 

The implementation of the file TO functions helps to 
hide the difference in data types used for 
loading, as they provide the respective prototypes 
for the game engine and the resulting call remains 
the same 

LoadDataFile ( FileName ) ; 
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The framework 


• Sprite blitting 

- Blitting functions should be basic and 
platform independent 

void Blit ( applet *curApp, G3word xPos, G3word yPos, G3word width, 
G3word height, void *data, G3word xSrc, G3word ySrc, G3Raster0p 
mode ) 

- Provide image clipping 

- Especially in mobile development U/V- 
mapping of sprites in a large source-bitmap 
is advisable to save memory 

- Make sure to always, always clip your 
sprites against the screen dimensions 
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Example of a high-level blitting implementation 
in Brew 


void 

Blit ( applet *curApp, G3word xPos, G3word yPos, G3word width, G3word height, void *data, 

G3word xSrc, G3word ySrc, G3Raster0p mode ) 

{ 

if ( xPos < curApp->ClipRect . lef t ) 

{ 

width += xPos - curApp->ClipRect . left; 
xSrc -= xPos - curApp->ClipRect . left; 
xPos = curApp->ClipRect . left; 

} 

else if ( ( xPos + width ) > ( curApp->ClipRect . lef t + curApp->ClipRect . right ) ) 

{ 

width = width - ( xPos + width - ( curApp->ClipRect . lef t + curApp->ClipRect . right ) ); 

} 

if ( yPos < curApp->ClipRect . top ) 

{ 

height += yPos - curApp->ClipRect . top; 
ySrc -= yPos - curApp->ClipRect . top; 
yPos = curApp->ClipRect . top; 

} 

else if ( ( yPos + height ) > ( curApp->ClipRect . top + curApp->ClipRect . bottom ) ) 

{ 

height = height - ( yPos + height - ( curApp->ClipRect . top + curApp->ClipRect . bottom ) ); 

} 

if ( width > 0 && height > 0 ) 

{ 

IDISPLAY BitBlt ( curApp->a.m pIDisplay, xPos, yPos, width, height, data, xSrc, ySrc, mode ); 

} 
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The framework 


• Debug Logging 

- Create a basic set of functions to log, 
protocol or dump data into file 

- Add functionality to log, protocol or dump 
data to the debugger output window 

- Debug functions can be performance drains, 
so make sure you wrap them so that the 
calls can be easily removed in your 
release builds 
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The framework 


• Stdlib functions 

- Even though most functionality is available 
across platforms, its performance varies 
dramatically 

• Brew does not allow support stdlib functions and instead 
utilizes substitute functions 

• When compared to their library counterparts, memcpy ( ) for 
example can be implemented twice as fast in a simple C- 
loop in Brew, while it is virtually unbeatable in Windows 
CE 

- Create an abstraction layer to isolate all 
calls to external library functions for 
flexibility. That way you can simply 
redirect to the stdlib function or write 
your own implementation when necessary 
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The framework 


• Custom UI 

- Create your own UI class so you won't have 
to rely on UI features and implementations 
on actual handsets 

- Create functionality for text display, 
menuing using your own custom fonts 

• Eliminates problems stemming from firmware 
bugs 

• Eliminates problems from non-existing UI 
features across platforms, such as menus with 
icon, etc. 

• Creates a consistent look and handling across 
handsets and platforms 

^ ^ • It is ^pandahle and you have full control 

Game Developers Conference 2T)LJ4 ^ 

over it 
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The framework 


• Handset detection 

- Create a module that is dedicated to 
handset detection based on platform ids, 
OEM Strings, or the like 

- Make sure to also read-out the OS version 

- Retrieve handset specific information in 
this module and make it available to the 
application 
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Example of handset detection in Brew 

void 

DetectHandset ( applet *curApp ) 

{ 

handsetID devicelD; 

AEEDeviceInf o ddi = { 0 } ; 

const platformID *ptr; 

devicelD = INVALID_DEVICE; 

ddi .wStructSize = sizeof ( ddi ) ; 

ISHELL_GetDeviceInfo ( curApp->a.m pIShell, &ddi ) 
ScreenWidth = ddi . cxScreen; 

ScreenHeight = ddi . cyScreen; 

Language = ddi.dwLang; 

if (0 != ddi . dwPlatformID ) 

{ 

ptr = PlatformIDTable; 
while ( NULL != ptr->0EMID ) 

{ 

if ( ptr->0EMID == ddi . dwPlatformID ) 

{ 

devicelD = (handsetID) ptr->DeviceID; 
break; 

} 

ptr++; 

} 

} 

if ( INVALID_DEVICE == devicelD ) 

{ 

ptr = PlatformIDTable; 
while ( NULL != ptr->0EMID ) 

{ 

if ( ptr->Width == ScreenWidth && ptr->Height 

{ 

devicelD = (handsetID) ptr->DeviceID; 
break; 

} 

ptr++; 

} 

} 

curApp->HandsetID = devicelD; 

} 
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/ / Retrieve device information 
/ / from the handset 


// If the handset returns an ID 
// things are fairly easy. 


// If it does not return a unique ID 
// we will have to use other means... 


== ScreenHeight ) 
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Example of handset detection in Windows CE, Pocket PC and 
Smartphone 


void 

DetectHandset ( applet *curApp ) 

{ 

G3ustring string [64] = { 0 } ; // Unicode string required! 

if (0 != SystemParametersInfo ( SPI_GET0EMINF0, sizeof ( string ), &string[0], 0 ) ) 

{ 

ptr = PlatformIDTable; 

while ( NULL != ptr->DeviceID ) 

{ 

if ( 0 == wcsicmp( ptr->OEMString, string ) ) 

{ 

devicelD = (handsetID) ptr->DeviceID; 
break; 

} 

ptr++; 

} 

} 

} 
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• Use the information from the handset 
detection to drive your application 

I am typically using a structure with all the relevant variables 
for a number of key handsets 


typedef struct 

{ 


G3wordl6 SoundIdleDelay ; 

G3bool DeviceAllowsSoundPause ; 

G3wordl6 ScreenQuadX; 

G3wordl6 ScreenQuadY; 

G3wordl6 ScreenLogoX; 

G3wordl6 ScreenLogoY; 

} deviceConf ig; 


static const deviceConf ig DeviceConf igs [ ] = 

{ 

{ 1, TRUE, 64, 65, 24, 30 } ; // Motorola t720 

{ 40, TRUE, 60, 57, 22, 24 } ; // LGE VX6000 

NULL 


Frequently, certain handsets can safely use the exact same 

configurations, so we then identify the key handset from the 
obtained handset information 

switch ( curApp->HandsetID ) 

{ 

case AUDIOVOX_CDM8400 : 
case AUDIOVOX_CDM8410 : 
case AUDIOVOX_CDM8600 : 

curApp->KeyDeviceID = USE_AUDIOVOX_CDM8 600 ; 
break; 
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Now all we have to do is, create a pointer to the correct device 
configuration data for the key handset that we determined 

curApp->DevCf g = SDeviceConf igs [ curApp->KeyDeviceID ] ; 


We now have easy access to all sorts of variables that can be hand- 
optimized for particular handsets. These can contain delay values, 
flags to avoid certain function calls and circumvent firmware bugs, 
placement coordinates, filenames to allow for swapping out images or 
sounds or anything else you can think of 

void 

SoundSuspend ( applet *curApp ) 

{ 

if ( NULL != curApp->Sound ) 

{ 

if ( TRUE == curApp->DevCfg->DeviceAllowsSoundPause ) 

{ 

ISOUNDPLAYER_Pause ( curApp->Sound ) ; 

} 

else 

{ 

ISOUNDPLAYER_Stop ( curApp->Sound ) ; 

} 

} 

} 


This data-driven architecture minimizes code-changes especially for 

handset ports and substitutes them with easy to edit data structures in 
one place 
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Accommodating screen 

resolutions 


Screen resolutions on mobile 
phones can be a nightmare and 
range from anywhere between 
96x54 to 240x320 pixels and 
above 

Using the device configuration 
table described before will make 
dealing with these resolutions 
much easier, especially when 
combined with a little trick 
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Splicing 


Splicing takes different graphic 
elements and draws them in a way 
that creates a seamless image 
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Splicing 


Through different positioning it 
allows us to create backgrounds 
in various sizes on the fly 
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Flipit 


All 36 Brew handset versions of "Flipit!" are us 
resolutions and screen layouts were achievec 
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Some final thoughts 


• Always apply common sense and try to think 
ahead 

• Always document your code and use variable 
and function names that are sensible and 
self-explanatory 

• Use Assertions liberally. They can not only 
detect errors in your program logic, but also 
reveal porting issues between handsets and 
platforms, such as incorrect endianness, 
alignment issues, corrupt data, etc. 

• Consciously look for and isolate platform and 
device dependencies, even if it means some 
extra work 
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Some final thoughts 


• If your data structures change while you're 
developing a later handset, make sure to make 
the correct adjustments in ALL your previous 
configurations. Never leave your code open- 
ended or prone to bugs 

• While you are doing the initial handset 
implementations, make as many as possible, 
even if they're not immediately reguired. It 
is much easier to make handset ports while the 
code is still fresh in your mind than having 
to go back again later 

• Once you are done with the application, lock 
down your game engine code so it will not be 
broken by future handset ports. You can use 
revision control systems to do that or simply 



Some final thoughts 


• Properly document the steps necessary to build 
the application 

• Document the steps that are necessary to 
implement a new handset version 

• Never #ifdef your way through code. It is the 
least portable solution - a hack in essence - 
and typically only introduces errors in 
versions and builds that were working fine 
previously 

• In general^ try to touch as little code as 
possible when doing ports. The less code you 
change, the smaller the chance of introducing 
new bugs ! 
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Book recommendations 


• Writing Solid Code, by Steve Maguire 
Microsoft Press, AISN 1556155514 

• Code complete, by Steve McConnell 
Microsoft Press, ISBN 1556154844 

• Code Reading, by Diomidis Spinellis 
Addison-Wesley , ISBN 0201799405 

• Effective C++, by Scott Meyers 
Addison-Wesley, ISBN 0201924889 
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